A flaw was found in 389 Directory Server (389-ds-base). In idssaslcheckbind(), on a successful SASLOK from the underlying Cyrus SASL library, the connection is marked SASL-complete and bind credentials are installed via bindcredentialssetnolock() before the account-lock check (slapicheckaccountlock()) is performed for non-root binds. If the subsequent lock check determines the account is locked (nsAccountLock: true), the bind is failed and reported to the client, but the already-installed SASL-complete flag and bind credentials are not reverted. A client that already knows the correct password for an account that has since been administratively locked can bind via SASL PLAIN, receive an "account locked" failure response, and continue using the same, already-authenticated TCP connection to perform further LDAP operations as that account -- defeating account lock as an access-revocation control. Setting nsslapd-close-on-failed-bind does not mitigate this. This finding was independently reported by two unrelated parties (OpenAI Security Research and Andrew Rukin of Arenadata) who converged on the identical root cause.